\subsection{D\'ecouverte des outils MIA-Studio}
\label{sec:mia_studio}

\begin{figure}[H]
\centering
\includegraphics[scale=0.70]{images/mia_studio.png}
\caption{Mia-Studio}\label{fig:mia_studio}
\end{figure}

La première activité du stage a été la formation aux outils MIA-Studio à savoir MIA-Transformation et 
MIA-Generation (voir \ref{fig:mia_studio}). 
Ces outils sont issues du pôle recherche et développement de \textsc{Sodifrance} et se positionnent dans 
le contexte du \GLS{mde}.
La réalisation de tutoriaux basés sur des cas d’utilisation mon permis de
prendre en main ces outils.

\subsubsection{MIA-Transformation}
\label{sec:mia_transfo}

\begin{figure}[H]
\centering
\includegraphics[scale=0.63]{images/mia_transfo.png}
\caption{Mia-Transformatoin}\label{fig:mia_transfo}
\end{figure}

MIA-Transformation permet la transformation de modèles sources vers des modèles
cibles. Il prend en charge de multiples formats d'entrées ou de sorties
(\GLS{xmi}, API, \gls{repository}, et autres). Des règles d'inférences
permettent de réaliser les transformations avec l'aide de services additionnels se présentant sous la forme
de script \textsc{Java} et permettant de faire des traitements spécifiques sur
les éléments traités.

\subsubsection{MIA-Generation}
\label{sec:mia_gene}

\begin{figure}[H]
\centering
\includegraphics[scale=0.65]{images/mia_gene.png}
\caption{Mia-Generation}\label{fig:mia_gene}
\end{figure}

MIA-Generation permet de mettre au point des générateurs de code compatible avec
des architectures et des frameworks spécifiques. Son environnement de
développement permet la spécification des règles de génération basée sur
l'utilisation de templates.
Il permet des cycles de développement itératifs avec préservation de fragments
de code générés entre les itérations, et est intégré sous forme de plugin à
d'autres environnements tels que \textsc{\Gls{eclipse}},
\textsc{\gls{magic_draw}}, \textsc{\Gls{maven}}.

\subsection{Analyse de l'existant}
\label{sec:state_of_art}

\subsubsection{Cartographie des applications (Couche DAO)}
\label{sec:carto}

La figure \ref{fig:code_item_diagram} est un extrait du modèle servant à
représenter la cartographie des applications. On distingue en générale 2 types
de cartographie:\\
\begin{itemize}
  \item \emphbf{La cartographie statique} basée sur l'analyse de code source, 
  permettant d'en tirer des métriques (SLOC, complexité, complexité
  cyclomatique, \ldots) ou encore le découpage du code selon une hiérarchie
  d'éléments.
  \item \emphbf{La cartographie dynamique} permettant d'analyser la dynamique
  de l'application (les flots de contrôles, enchaînement des écrans, \ldots).\\
\end{itemize}

L'outil MIA-Generation (présenté dans la section \ref{sec:mia_gene}) est
utilisé, pour générer à partir de ce modèle, une API \textsc{Java} permettant d'exploiter ces données de
cartographie. 

L'API ainsi généré utilise l'\GLS{orm}  fournis par le framework
\textsc{\Gls{hibernate}} comme support pour la persistance des objets du modèle.
Cela permet aux développeurs d'accéder aux éléments du modèle dans le formalisme \textsc{Java},
et aussi fournit une possibilité de choix sur le support de stockage des données
(\gls{mysql}, Microsoft SQL Server, Oracle, \ldots).

Le code source est découpé en différentes entités communément référencées
dans les différents paradigmes de programmation et pouvant être en relation les
unes avec les autres. On peut citer les modules, les classes, les méthodes, les paramètres, 
les écrans, etc \ldots.

Toutes ces entités (cf \ref{fig:code_item_diagram}) sont les descendants d'un
type de base \emphbf{CodeItem} et possèdent une clé (\emph{ElementKey}) permettant de
les identifier de manière unique, cette clé permet de suivre l'élément durant
tout le processus de migration.\\

\begin{itemize}
  \item Une classe est représentée dans le modèle par l'élément
  \emphbf{ClassUnit}.
  \item Un écran par l'élément \emphbf{Screen}.
  \item Une méthode par l'élément \emphbf{CallableUnit}.
\end{itemize}

\begin{landscape}
\begin{figure}[H]
\centering
\includegraphics[width=1.30\textheight]{images/Class_Diagram__data__CodeItems__CodeItemsDiagram.png}
\caption{Modèle de cartographie : Diagramme de
suivi}\label{fig:code_item_diagram}
\end{figure}
\end{landscape}

\subsubsection{Le suivi de l'avancement de l'intégration}
\label{sec:suivi_integration}

Le suivi de l'avancement de l'intégration est assuré au niveau des
\emph{CodeItem} qui, comme vu précédemment, peuvent être des classes, des
méthodes, des paquetages, des modules et bien d'autres.

Tout comme les éléments cartographiés, le suivi est persisté dans une base de
données et accessible à travers la même \GLS{dao} que celle utilisée pour la
manipulation du modèle (cf section \ref{sec:carto}). Le schéma
\ref{fig:project_management} extrait du modèle de cartographie présente les
éléments utilisés pour réaliser le suivi. On peut y observer: \\
\begin{itemize}
  \item \emphbf{WorkProgressSnapshot} qui correspond à une image de l'état
  d'avancement du code intégré à un moment donné.
  \item \emphbf{CodeItemStatus} permet de représenter l'état actuelle d'un
  \emph{CodeItem}.
  \item \emphbf{CodeItemProgressStatus} permet de représenter l'état d'un
  \emph{CodeItem} à un moment donné correspondant à une image de suivi
  d'avancement. Ce qui permet de suivre l'évolution de l'intégration d'un
  élément au cour du temps.
  \item \emphbf{CodeItemProgressStatusKind} est une énumération permettant de
  représenter les différents états par lequel transite un \emph{CodeItem}
  pendant le processus de modernisation. Dans un cycle normale d'intégration un
  élément est initialement \emph{en attente} d'intégration, puis \emph{en cours}
  d'intégration et finalement \emph{intégré}.\\
\end{itemize}

La création d'une image de suivi se fait par l'analyse du code encours
d'intégration. Les éléments à suivre sont identifiés lors de l'analyse à l'aide
de leurs clés uniques. L'état des éléments identifiés est déterminé par la
présence ou l'absence de tags.

Un tag se compose au minimum d'une chaine de caractère permettant de le typer,
et la clé de l'élément concerné. Comme type tag on peut citer:
\begin{itemize}
  \item Le tag de début d'intégration.
  \item Le tag de fin d'intégration.
  \item Le tag de suivi.
  \item Les tags de ToDo.
\end{itemize} 

Le schéma \ref{fig:state_by_tag} montre comment peut évoluer
l'état d'avancement d'un élément intégré en fonction de la présence ou de
l'absence de tags.

\begin{landscape}
\begin{figure}[H]
\centering
\includegraphics[width=1.25\textheight]{images/Class_Diagram__data__ProjectManagement__ProjectManagementDiagram.png}
\caption{Modèle de cartographie : Diagramme des
éléments de code}\label{fig:project_management}
\end{figure}
\end{landscape}

\begin{figure}[H]
\centering
\colorbox{imgBackground}{\includegraphics[scale=0.65]{images/state_by_tag.png}}
\caption{Evolution de l'état d'avancement en fonction
des tags de suivi}\label{fig:state_by_tag}
\end{figure}

\subsubsection{L'outil existant}
\label{sec:current_tool}
\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{images/old_interface.png}
\caption{Ancienne interface Swing}\label{fig:old_interface}
\end{figure}

L'interface graphique présentée par la figure \ref{fig:old_interface} était
utilisée pour le calcul d'avancement et la génération de rapports de suivi . Cette interface 
s'appuyait principalement sur deux couches logicielles:
\begin{itemize}
  \item Une couche données accessible via une \GLS{dao} (evoquée dans la
  section \ref{sec:carto}).
  \item Une couche services regroupant les traitements réalisables (ex:
  Génération de rapports sous différents formats \textit{*.graphml},
  \textit{*.xls}, \ldots).
\end{itemize}
	
Dans cette version les données d'accès à la base de données de suivi sont
stockée dans un fichier de configuration \gls{hibernate} se trouvant à la racine
du projet. L'utilisateur doit configurer les options de suivi (répertoire
d'intégration, répertoire de génération, etc \ldots) avant de lancer les
différents algorithmes.

La plateforme réalisée s'appuie sur cette version pour proposer ses
fonctionnalités. Elle utilise en effet les mêmes couches logicielles que cette
dernière et adapte les différents algorithmes à son environnement.

\subsection{L'environnement \textsc{Eclipse}}

\begin{figure}[H]
\centering
\includegraphics[scale=0.55]{images/eclipse-platform-arch.png}
\caption{Architecture de la plateforme eclipse}\label{fig:eclipse_plateforme}
\end{figure}

Le plateforme développée doit étendre l'environnement \textsc{\gls{eclipse}}
pour y rajouter des fonctionnalités de suivi. Il peut donc être utile d'avoir des
connaissances sur l'architecture de la plateforme \textsc{\gls{eclipse}} pour
envisager son extension.

\begin{itemize}
  \item L'architecture d'\textsc{\Gls{eclipse}} est une architecture basée sur
  l'assemblage de composants. Elle est mise en oeuvre selon les spécifications
  de l'\GLS{osgi} depuis sa version 3;
  spécifications dont elle propose une implémentation produite sous l'appellation
  \textsc{Equinox}. Le framework spécifié par l'\GLS{osgi} propose:
  \begin{itemize}
    \item Une plateforme basée sur des services.
    \item Un modèle de gestion du cycle de vie d'une application.
    \item Un registre de services.
    \item Un environnement d'exécution des modules.
    \item Des couches de fonctionnement et des API.
  \end{itemize}
  \item Comme on peut l'observer sur la figure (\ref{fig:eclipse_plateforme}),
  la plateforme se compose d'un socle minimale nécessaire à son lancement. Ce
  socle comprend:\begin{itemize}
    \item Une interface utilisateur (SWT/JFace/Workbench).
    \item Un \textit{Workspace} pour la gestion des ressources.
    \item La gestion du travail collaboratif et d'un système d'assistance.
  \end{itemize}
  \item Le socle minimale est complété par un système de plugins/points
  d'extensions permettant d'ajouter des fonctionnalités en se branchant sur un
  ensemble de plugins fournis en natif.
  \item L'ajout de fonctionnalités ou l'extension de la plateforme
  \textsc{\Gls{eclipse}} sont réalisés grâce à l'ensemble d'outils regroupés dans l'
  \textsc{\Gls{eclipse}} \gls{pde}. Cet ensemble d'outils permet de créer,
  développer, tester et déployer des produits \textsc{\Gls{eclipse}} ou encore des
  bundles \GLS{osgi}.\\
\end{itemize}

%\clearpage